Modern computing systems nowadays involve a plurality of physically distinct computer connected over networks such as the Internet. In such distributed environments, the concept of service-oriented architectures (SOA) has become increasingly popular. In a SOA, the individual computers offer their functionality in the form of services, which are well-defined pieces of functionality defined by an interface. One service provides functionality to the other services, so that the overall computing task is performed in that the services interact with each other, each fulfilling a piece of the overall task.
As a result, a SOA provides a more flexible architecture by splitting monolithic applications into components that can be reused and orchestrated to get new functionality on demand. New or changed processes (which include technical processes, such as the control of an assembly line, and also business processes) can be implemented by combining existing services and/or other types of SOA assets.
Since the implementation of a SOA leads to a collection of distributed and loosely coupled services, maintaining interoperability and reusability in such an environment is a particularly difficult task, which is commonly referred to as “SOA governance”. Besides the technical aspects of interoperability and reusability, SOA governance also has to address other aspects, such as the enforcement of security or legal regulations on SOA components.
SOA governance can be split into design-time and runtime governance. The design-time governance concerns the management of the participating SOA assets in a SOA registry/repository, the enforcement of design-time policies, lifecycle management and the versioning of SOA assets. The runtime governance concerns aspects such as monitoring the runtime interaction between the SOA assets and enforcing runtime polices. The runtime policies are typically deployed into so-called runtime containers of SOA assets and enforce the proper interactions between the SOA assets, which may include the rejection of unauthenticated accesses and/or checking the standard compliance of SOA asset invocations.
In the prior art, a variety of SOA registries/repositories are known (e.g. CentraSite of applicant, Systinet, WSRR, SOA Software, Oracle Enterprise Repository), which offer design-time governance features, such as the registration of SOA assets, lifecycle management (cf. e.g. US 2010/0095266 A1), and the enforcement of design-time policies. Some of the existing products also offer the capability of defining the runtime policies and deploying them to runtime containers (also called policy enforcement points). Moreover they are able interoperate with runtime governance products that monitor runtime interactions and report metrics data and runtime events. Certain runtime products are addressing the rogue services detection by monitoring service runtime interactions (e.g. Progress). Advanced rogue service detection goes beyond the runtime monitoring by applying so-called service harvesting, which can be performed by checking runtime containers to find out which services are deployed (cf. e.g. US 2010/0161629 A1). In summary, all of the existing products are either focused on the above-explained design-time governance or the runtime governance.
However, there is always the risk of a control gap between design-time and runtime governance. This gap can e.g. be caused by services which are not registered in the SOA registry/repository (so-called “rogue services”), thereby completely bypassing any design-time governance. It can also be caused by registered services violating the design-time governance during runtime, e.g. when a service is calling other services which it is not allowed to call, or when a service can already be deployed to the production runtime container albeit the service's lifecycle state in the SOA registry/repository defines that it is still under development. All these problems are caused by the fact that the runtime governance is not in line with the design-time governance.
It is therefore the technical problem underlying the present invention to provide a way of ensuring that all design-time policies for a given SOA are effectively and reliably enforced during runtime, thereby at least in part overcoming the above explained disadvantages of the prior art.
This problem is according to one aspect of the invention solved by a computer-implemented method for enabling the enforcement of design-time policies during runtime in a service-oriented architecture (SOA). The SOA comprises a plurality of SOA assets, such as web services, and at least one runtime container, the runtime container being adapted for enforcing runtime policies on SOA assets executed therein. In the embodiment of claim 1, the method comprises the following steps:    a. obtaining at least one design-time policy from a SOA registry of the SOA, wherein the at least one design-time policy applies to a plurality of SOA assets grouped into a design-time domain;    b. automatically deriving at least one runtime policy from the at least one design-time policy and at least one runtime domain from the design-time domain, the runtime domain indicating at least one runtime container;    c. performing a compatibility check to determine whether the at least one runtime policy can be enforced by the at least one runtime container; and    d. depending on the result of the compatibility check, automatically deploying the at least one runtime policy to the runtime container.
This embodiment proposes an approach for closing the above-explained control gap by reliably combining design-time and runtime SOA governance, wherein it is ensured that the runtime governance comprehensively covers the design-time policies. This way, it is ensured that no services or other types of SOA assets violate the design-time governance during runtime, which includes both unregistered “rogue” services and registered services not following the design-time governance during runtime.
The above objectives are achieved in that the embodiment is based on the definition of domains, i.e. groupings of SOA assets, so that the approach allows to automatically derive runtime policies from a set of given design-time policies that are enforcing the domain structure. In particular, domains are advantageous for enforcing the domain structure also on rogue services. Since rogue services are not registered in the SOA registry/repository (see above), design-time policies cannot be directly attached to them. Therefore, in accordance with the invention the design-time domains are translated into runtime domains, which in turn represent a collection of runtime containers. Enforcing policies on these runtime domains ensures that rogue services are addressed properly. A given SOA may be structured into domains according to various aspects, such as the technical runtime environment suitable for a group of assets, or the like. The concept of domains simplifies the definition of policies governing the interaction between services and enables an automatic and, most importantly, comprehensive definition and deployment of runtime policies from a set of given design-time policies. In addition, since a compatibility check is performed before the SOA assets are deployed to runtime containers, it is ensured that SOA assets execute only in such runtime containers which can actually enforce the defined policies. This way, it is ensured that the design-time governance is effectively and comprehensively enforced during runtime. It is noted that the above-mentioned US 2010/0161629 A1 also concerns a governance framework based on domains, however, the framework does not address the definition of domain policies and their automatic and comprehensive deployment to runtime containers. In fact, none of the above-discussed approaches of the prior art provides a method for automatically enforcing design-time policies during runtime in a safe manner.
In one aspect of the present invention, the at least one design-time policy defines at least one restriction to be met by the SOA assets within the respective design-time domain. Accordingly, such domain-internal policies specify certain restrictions and/or regulations that do not consider the interaction with other domains. Examples are a policy which checks the proper authentication for Web service calls, or a policy which verifies that manufacturing services are supposed to only call services that are following certain manufacturing-relevant regulations.
Additionally or alternatively, the at least one design-time policy may define at least one restriction to be met by an interaction between two SOA assets from different design-time domains. By addressing the interactions between domains, such extra-domain policies enforce the domain structure and/or certain interaction rules. An example for such a domain policy is the restriction that services of the development domain are not supposed to be called by services of any other domain, which ensures that sensible development data are not spread across the organization. In other words, the policy effectively introduces a firewall around the services of the development domain, which may be managed e.g. by a special approval service, such as offered by the CentraSite SOA registry/repository of applicant. A further example is to restrict the set of services that can be called by the services of the development domain.
This ensures that the development services are only dependent on reliable services, in that it provides a set of domains that are allowed to be called by services of the development domain.
Preferably, the design-time policies and/or the runtime policies comprise one or more WS-Policy assertions adhering to the WS-Policy specification.
In another aspect of the present invention, performing the compatibility check may comprise obtaining at least one capability definition of the runtime container from the SOA registry and comparing the at least one capability definition of the runtime container with a required capability of the runtime-policy. Accordingly, each policy may define one or more capabilities needed in order to be enforced, and it is ensured that the policy is only deployed to a runtime container which has the desired capability, i.e. which is able to enforce the policy.
In yet another aspect, the at least one design-time policy may be defined in the SOA registry independent of a specific runtime container and the compatibility check may be performed based on a mapping obtained from the SOA registry, wherein the mapping maps the design-time domain onto at least one runtime domain, the runtime domain comprising the runtime container. This way, an automatic yet comprehensive and safe deployment is made possible.
Furthermore, the present method may comprise the further step of issuing a notification, if the at least one runtime policy cannot be enforced by the runtime container. Accordingly, the automated deployment process ensures that gaps in the automated deployment process are properly detected and can then be eliminated.
According to a further aspect of the invention, the design-time domain and/or the runtime domain may be defined in at least one taxonomy of the SOA registry. Taxonomies allow for a particular flexible definition of an arbitrary complex domain structure, as will be further explained in the detailed description below.
The present invention also provides a SOA registry for enabling the enforcement of design-time policies during runtime in a service-oriented architecture, wherein the SOA comprises a plurality of SOA assets, such as web services, and at least one runtime container, the runtime container being adapted for enforcing runtime policies on SOA assets executed therein, wherein the SOA registry comprises a policy storage, adapted for storing at least one design-time policy, wherein the at least one design-time policy applies to a plurality of SOA assets grouped into a design-time domain, means for automatically deriving at least one runtime policy from the at least one design-time policy and at least one runtime domain from the design-time domain, the runtime domain indicating at least one runtime container, means for performing a compatibility check to determine whether the at least one runtime policy can be enforced by the at least one runtime container, and means for, depending on the result of the compatibility check, automatically deploying the at least one runtime policy to the runtime container. Further advantageous modifications of embodiments of the SOA registry of the invention are defined in further dependent claims, wherein the SOA registry may be adapted for performing any of the above-described methods.
Also a service-oriented architecture (SOA) system is provided, the system comprising an SOA registry as described above and at least one runtime container. Lastly, the present invention relates to a computer program comprising instructions for implementing any of the above-described methods.